Is findCharacters allowed to be more than one characters?

Thank you for feed back, I see that I have make some validation error. I can see that instead of validation for just a specific character. So instead I will change this test so that is can check correctly

Could consider testing a few more samples in this script - higher chance to detect bugs in code.

The original specification did not clearly state whether the character match should be case-sensitive.
Most people would probably assume that it is, but to demonstrate our understanding or clarify the assumption we made,
we could add test cases to convey this. For examples,

• A case to show that the match is case sensitive
• A case to show that the function is expected to work also for non-alphabets

@cjyuan Thank you for the suggestion here is my jest test case for this 2 scenario:

// Scenario: Case-sensitive matching
// Given a string containing both uppercase and lowercase versions of a letter,
// When the function is called with a lowercase character,
// Then it should only count the lowercase occurrences.

test("should treat character matching as case-sensitive", () => {
expect(countChar("AaAa","A")).toEqual(2);
});

// Scenario: Non-alphabet characters
// Given a string containing digits and symbols,
// When the function is called with a non-alphabet character,
// Then it should correctly count occurrences of that character.

test("should count occurrences of non-alphabet characters", () => {
expect(countChar("1-2-3-1-1","1")).toEqual(3);
});

Can you look up the pros and cons between these two styles of expressing the code?

  if(num % 100 === 11 ||num % 100 === 12 || num % 100 === 13 ){

  const lastTwoDigits = num % 100;
  if (lastTwoDigits === 11 || lastTwoDigits === 12 || lastTwoDigits === 13 ) {

?

@cjyuan Thank you for the feed back,

I see that that for the first line the main pro is that :

• The pros is that the code shorter, no extra variable and is good for when 1 argument pass to each condition.
• The cons is that the code it harder to understand for some new beginner and might caught with unexpected error. Also the argument num is now pass 3 time for each condition and it can cause issue if the code is broke outside the function.

For the second line I see that:

• The pros of this line is that is more solid and safer then the first line. It help other coder or beginner to understand the code easier. Also the value now store inside a container that can be used safely and if need be can be change later.
  The cons for this line of code as far as I can see is that is only add 1 more line of code.

So after I see both Pros and cons of these 2 line, understand for the best I will used the second line of code since is more save and easier to change and fix. I will make this change inside my code. Thank you.

Why do you decide to round the numbers with decimal places? Why not reject them?

For this one I, the main reason is that since I would like to for the function to work even is the user pass a float number value. When pass inside the function the argument num will automatically will be round to their nearest number then do the reminder. But I see now is might caught the issue since it will return not what the user put in so I will max change that reject the decimal value.

When a test fails with the message "... all other numbers", it may be unclear what "other numbers" actually refers to.
Can you revise the test description to make it more informative?

Thank you for the feed back I will fix it right away

What do you think about this writing style?

if (repeatCount === 0) return "":

return fullString.repeat(repeatCount);

Thank you for the reply , I think that if I used the same method as you using with this line code. It will run and return the value just fine since is a if else statement but more shorthand compact. I understand that by using switch case is make make the code look better but in long term can cause some issue in the long run. So for the best I will try this if else style for easier reading and maintain the code.